Graphics processing is an important feature of modern high-performance computing systems. In graphic processing, mathematical procedures are implemented to render, or draw, graphic primitives, e.g., triangles or rectangles, on a display to produce desired visual images. Real time graphics processing is based on the high-speed processing of graphic primitives to produce visually pleasing moving images.
Early graphic systems were limited to displaying image objects comprised of graphic primitives having smooth surfaces. That is, visual textures, bumps, scratches, or other surface features were not modeled in the graphics primitives. To enhance image quality, texture mapping of real world attributes was introduced. In general, texture mapping is the mapping of an image onto a graphic primitive's surface to create the appearance of a complex image without the high computational costs associated with rendering actual three dimensional details of an object.
Graphics are typically produced by graphics designers who use application program interfaces (API's), which are standardized software interfaces, to render desired images that can be run on multiple platforms, operating systems; and hardware. Examples of API's include the Open Graphics Library (OpenGL®) and D3D™. This enables graphic designers to design graphics without knowing any of the specifics regarding the system hardware or how their commands will be implemented.
FIG. 1 illustrates a simplified block diagram of a graphics system 100 that includes a graphics processing unit 102. As shown, that graphics processing unit 102 has a host interface/front end 104. The host interface/front end 104 receives raw graphics data from a central processing unit 103 that is running an application program stored in memory 105. That application program can be input from a computer readable medium 105A. The host interface/front end 104 buffers input information and supplies raw graphic information to a geometry engine 106. The geometry engine has access to a frame buffer memory 120 via a frame buffer interface 116. The geometry engine 106 produces, scales, rotates, and projects three-dimensional vertices of graphics primitives in “model” coordinates that are stored in the frame buffer memory 120 into two-dimensional frame-buffer co-ordinates. Typically, triangles are used as graphics primitives for three-dimensional objects, but rectangles are often used for 2-dimensional objects (such as text displays).
The two-dimensional frame-buffer co-ordinates of the vertices of the graphics primitives from the geometry engine 106 are applied to a rasterizer 108. The rasterizer 108 identifies the positions of all of the pixels within the graphics primitives. This is typically performed along raster (horizontal) lines that extend between the lines that define the graphics primitives. The output of the rasterizer 108 is referred to as rasterized pixel data.
The rasterized pixel data are applied to a shader 110 that processes input data (code, position, texture, conditions, constants, etc) using a shader program (sequence of instructions) to generate output data. Shaders can be considered as a collection of processing capabilities that can handle large amounts of data at the same time, such as by parallel processing data.
The shader 110 includes a texture engine 112 that modifies the rasterized pixel data to have the desired texture and optical features. The texture engine 112, which has access to the data stored in the frame buffer memory 120, can be implemented using a hardware pipeline that processes large amounts of data at very high speed. The shaded pixel data is then sent to a Raster Operations Processor 114 (Raster op in FIG. 1) that optionally performs additional processing on the shaded pixel data. The result is pixel data that is stored in the frame buffer memory 120 by the frame buffer interface 116. The frame pixel data can be used for various processes such as being displayed on a display 122.
The foregoing overview of graphics systems has presented a simplified view of graphics. In practice, a graphics designer often works with texture bitmaps that are tiled to produce a graphic design. For example, a brick wall can be formed by taking a simple texture bitmap, say a several brick separated by mortar, and then tiling that texture bitmap to form a wall. While the foregoing is accurate as far as it goes, it too is also somewhat simplified. While a good image of a wall from a “head-on” view can be formed by tiling the same texture bitmap over and over, when the view changes to an angle or to perspective, the texture bitmap should be changed. After all, a brick that is perceptively far away is smaller, and thus takes fewer pixels to show, than a close brick. However, simply eliminating pixels can cause visual problems. However, changes to a texture bitmap can be implemented using mipmaps, i.e., texture bitmaps having size variations.
FIG. 2 illustrates how a simple image can become complicated by a simple change in perspective. A graphical image 200 represents a more or less “head-on” view of a tiled structure comprised of blocks formed by lines 202-210. When a viewer's viewpoint changes to an upward angle the lengths of the lines 204-210 change as shown in FIG. 201. If each block is a textured bitmap the visually far away textures require fewer pixels and those pixels form a more elongated shape. In general, the process of determining which texels map to screen pixels is called “texture sampling and filtering.”
To ensure a realistic appearance the texture tiles close to a viewer's perspective must look very detailed while those farther away become less detailed. While some detail loss is inevitable, good texture filtering minimizes and controls detail loss while providing a natural look. For example, a word on a wall far away should not simply disappear because its lines are formed by eliminated pixels. Without texture filtering an image can become highly pixilated (splotches caused by lost pixels). To avoid pixilation effects many graphic forming and editing programs allow a graphics designer to implement various types of filtering. For example, a simple point sampling routine samples the nearest texel, a bilinear filter samples a 2×2 area of the texture and then averages, and a trilinear filter samples a 2×2 on one mip level, a 2×2 on the next mip level, and interpolates between the two values.
While the foregoing filtering techniques improve graphics quality, the best filtering method is often anisotropic filtering. In anisotropic filtering pixels are not derived from a symmetrical shape. Rather, pixels are formed by increasing the samples along the “long edge” of the figure and then interpolates as in trilinear filtering. The number of pixels used for filtering determines the filter level. 1× anisotropic filtering uses 8 pixels, 2× anisotropic filtering uses 16 pixels, 3× anisotropic filtering uses 24 pixels, and so on. Some graphics cards can achieve 16× anisotropic filtering (128 pixels). However, the higher the anisotropic filtering level the more computation time is required to implement the filter. Furthermore, with some images the visual difference between say 4× and 16× anisotropic filtering is difficult or impossible to detect, in other images the visual difference can be dramatic. Thus, sometimes 4× anisotropic filtering is highly beneficial because it produces high quality results relatively quickly while at other times 4× level anisotropic filtering is insufficient from an artistic viewpoint.
It is possible to implement graphics design packages that would allow a graphics designer to specify numerous editing and formatting attributes, including the type of filtering that is to be used. Such design packages would enable a designer to specify the level of filtering. Since high levels of anisotropic filtering does not harm graphical views it might seem that a designer would simply choose the highest possible level of anisotropic filtering. Unfortunately, many design projects are subject to a computational budget. For example, a game designer might be given a computational budget that permits the game being designed to run with a specified performance at a specified frame rate at a specified resolution and on a specified graphics system. If that budget is exceeded performance may be compromised. To meet the computational budget a graphics designer may have to limit or even eliminate some of the numerous editing and formatting attributes at his disposal. Since high levels of anisotropic filtering require extensive computational time, an anisotropic filtering level that is too high can seriously reduce the computational budget available for other tasks. Thus a designer should often select a relatively minimal anisotropic filtering level to ensure that adequate computation resources are available to meet other requirements.
In the prior art a graphics designer had little but his experience and trial and error to assist him when selecting an appropriate anisotropic filtering level. In practice, a designer could select an anisotropic filtering level and then note the impact of that level on his computational budget.
In view of the foregoing, a method of determining an appropriate anisotropic filtering level for a given image would be beneficial. Even more beneficial would be an automatic method of determining an appropriate anisotropic filtering level. Also beneficial would be a system and a method for reducing the impact of anisotropic filtering levels on computational budgets by enabling selection of an appropriate anisotropic filtering level for a given situation. A method of selecting an appropriate anisotropic filtering level and then automatically setting that level also would be beneficial.